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Single-board microcomputers offer hardware cosl-eftectiveness for 
implementing many real-time systems. A compatibla, resident, real- 
time executive program provides savings in soft.vare development 
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Single-board computers, or microcomputers, that contain 
central processor, read-write and programmable read- 
only memory, real-time clock, interrupts, and serial and 
parallel input/output all on one printed circuit board, 
have made feasible a whole spectrum of applications 
which previously could not be economically justified. 
Inese microcomputers have also opened up a range of 
applications where the high functional density of large- 
scale integration provides advantages over previous solu- 
tions such as hardwired logic or relatively expensive 
minicomputers. While microcomputers readily solve hard- 
ware requirements, software for single-board computer 
applications with real-time characteristics (which are 
in the majority) has until now been generated individu- 
ally for each application. 

The Intel RMX/80* Real-Time Multi-Tasking Execu- 
tive simplifies real-time application software development, 
and at the same time furnishes capabilities optimized for 
the microcomputer environment. It provides the means to 
concurrently monitor and control multiple external events 
that occur asynchronously in real-time. The program 
framework allows system builders to immediately imple- 
ment software for their particular applications, and to 
avoid specific details of system interaction. 

Major functions of the executive include system re- 
source access based on task priority, intertask communi- 
cation, interrupt driven device control, real-time clock 
control, and interrupt handling. In combination, these 
functions eliminate the need to implement detailed real- 
time coordination for specific applications. 

Previously, two alternative software approaches were 
used to solve microcomputer applications. First, many- 



designers created their own operating executive, i 
vidually tailored for each application. Obviously, 
approach was expensive and time-consuming. The se 
approach was to use a minicomputer executive whic" 
been adapted to a microcomputer. Since this so 
was designed for a different processing environmeti. .1 
then "stripped down," it suffered from major i 1 
equacies when executed on microcomputers. The altera 
tive, RMX/80, has been designed specifically to pro . ii 
a general-purpose real-time executive tailored to Int 
SBC 80 and System 80 microcomputers. 

Real-Time System Requirements ^ 

All software design approaches for use in real-time 1 
plications include capability for concurrence, prio . 
and synchronization/communication. 

Concurrence — Real-time systems monitor and cor.' 
events which are occurring asynchronously in the ph 
cal world. Microcomputer software does not know 
actly when external events will occur; however, it n: 
be prepared to perform the necessary processing u- 
demand, whenever the events actually do occur. Typ: : 
ly, interrupts are used to inform the microcomputer I 
an event has occurred. At interrupt time, system con 
software determines what processing to perform, as 
as the relative sequence in which processing must 
place. 



•KMX/80™ is a registered trademark of the Intel Corp. 5 
Clara. Calif. 
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Fig 1 A typical RMX/80 system. Mul- 
tiple tasks control a given application. 
Nucleus controls execution of both- 

. user and executive tasks through 
task-to-task communication, real-time 
clock, priority resolution, and inter- 
rupt handling facilities. All tasks with- 
in an RMX/80-based application use 
at least some of these capabilities; 

■ other optional executiv-e tasks include 
debugger, free-space manager, and 
device control for operator's console, 
diskette file system, analog subsys- 
tems, and high speed mathematics 
unit 



Programs related to external events are processed in 
an interleaved manner based on interrupt occurrence 
and priority. For instance, one routine is executing when 
an interrupt activates, signaling that a higher priority 
event has occurred. At this point, the routine related to 
the priority interrupt is started, while execution of the 
less important routine is discontinued temporarily. When 
the more important routine is completed, or temporarily 
halted for some other reason, execution of the less. im- 
portant routine is resumed. In this manner, multiple pro- 
grams execute concurrently in an interleaved fashion. 
Priority — In a real-time environment, certain events re- 
quire more immediate attention than others because of 
their significance within the physical world. Immediacy 
is. relative to other processing, and is determined by ap- 
plication requirements. The concept of immediacy or pri- 
ority, however, is common throughout all real-time micro- 
computer applications. In priority-based systems, the most- 
important program (one that is not waiting for some 
physical or logical reason) is the one executing. 

A classic illustration of program priority in real-time 
systems is found in the area of plant control. When the 
plant begins to fail in a nonrecoverable manner, it is 
•imperative that the plant be shut down as quickly as 
possible. For this reason, shutdown, processing takes 
priority over all other system demands. Software pri- 
ority enforces this hardware concept of physical opera- 
tional events. - . 

Synchronization/Communication — Another common sim- 
ilarity in most real-time systems is the need for synchro- 
nization between various events in the physical world 
which are under microcomputer control. Synchroniza- 
tion is defined as the process whereby one event may 
cause one or more other events to occur. Communication 
is the process through which data are sent between in- 
put/output (I/O) devices or programs and other pro- 
grams within the microcomputer system. 

An example of the need for synchronization and com- 
munication is a microcomputer system for weighing and 
stamping packages. One part of the system weighs the 
package, calculates pricing, and releases the package 
onto a conveyor belt. Price and weight data are com- 
municated to another part of the system which stamps 
the data onto the package after it arrives at a sensor 
station. Synchronization is demonstrated by the occur- 
rence of one event — package arrival — causing another 
event — package stamping— to occur. 

Compatible Benefits 

To satisfy real-time microcomputer software require- 
ments, the RMX/80 Real-Time Executive software (Fig 
1) was designed. This program differs from existing 
software systems by offering capabilities directly re- 
lated to the single-board microcomputer environment 
in which it operates. These capabilities have two major 
bottom-line benefits compared with equivalent minicom- 
puter systems. First, the executive code is compact 
enough to allow a large number of real-time applications 
to be processed on a single microcomputer board. To 
accomplish this capability, its nucleus is optimized to 
reside in less than 2k bytes [ie, in a single 16k program- 
mable read-only memory (p/ROM) j, thereby allowing up 
to 10K of onboard memory for application-related soft- 
ware and storage. 



Second, the executive may be p/ROM-resident. When 
the microcomputer system is powered on, the software 
system (executive plus application programs) is auto- 
matically initialized and begins execution of the highest 
priority application task. Typical major real-time execu- 
tives, however, are totally random-access read-write semi- 
conductor memory- (RAM) -resident, which means they 
must be initialized (booted) from a peripheral device, 
such as diskette, cassette, or communications line, into 
microcomputer memory. The need for peripheral devices 
significantly increases the total cost of traditional real- 
time executive-based solutions. 

Sample Application 

Functioning as a real-time executive for microcomputers, 
this software system provides facilities for orderly con- 
trol and monitoring of asynchronously occurring ex- 
ternal events. Although these events may differ widely 
from application to application, facilities are adaptable 
to nearly all processes where the microcomputers are 
used, including process and machine control, test and 
measurement, data communications, and specialized on- 
line data processing applications (where one or more 
terminals access diskette-based data). The executive is 
particularly useful in dedicated low cost applications 
which were not economically- feasible before the advent 
of microcomputers. For example, consider the require- 
ment of gas pump control in a service station (Fig 2). 

In this station, a microcomputer system operating 
with RMX/80 concurrently monitors and controls mul- 
tiple gas pumps, and sends price and volume informa- 
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turn to one central location. At the same time, informa- 
tion about station operation is being transmitted over a 
communications line to a regional computer. 

Individual tasks are developed independently 'to mea- 
sure pas flow, calculate and display price information, 
transfer data to the central computer, and monitor levels 
of gasoline in underground storage. All this processing 
takes place concurrently under program control. (Credit 
verification, charge slip printing, and billing can also 
be controlled by additional software tasks.) 

Efficient gas station operation demands that the hard- 
ware/software system be highly reliable. The compatible 
benefits of compact code, p/ROM residency, and self- 
initialization on a single-board microcomputer system all 
combine to ensure functional integrity. 

Software Structure 

RMX/80 simplifies the effort for developing a real-time 
system, first, by providing many commonly required 
software functions. Second, its software structure pro- 
motes efficient program development. Programmers who 
are familiar with structured programming will find task 
orientation both natural and easy to use. 

Tasking means that a larger program is divided into 
a number of smaller, logically independent programs or 
tasks. The key is to identify functions that may occur 
concurrently. For example, consider the tasks required 
for a terminal handler — real-time asynchronous I/O be- 
tween an operator's CRT terminal and the executive. 

Input Handler Task — One task must be ready to accept 
ii data character from the terminal at any time. This is 
done by responding to an interrupt signal from the 
terminal and then accepting the data character. The task 
immediately passes the input character to a subsequent 
task automatically and then goes back to wait for an- 
other interrupt. 

Line Buffer Task — As characters are received from the 
input handler they must be placed into a buffer to form 
a line. Eventually, the buffer will be filled or the logical 
end-oMine •■'ill be signaled by a carriage return char- 
. acter. At this point, the line buffer must be sent to some 
other task for processing. 

Echo Driver Task — For a full-duplex terminal, it is 
necessary to return each input character to the terminal 
for display on the CRT screen. This task waits for a 
character, which could be sent by either the line buffer 
or input handler task, and then sends the character to 
the terminal. It then waits for the next character. 

Note that input handler and echo driver are described 
as waiting for an event. Within the RMX/80, that is 
literally the case. While they wait, however, system re- 
sources are available for other tasks, such as that of the 
line buffer. Thus, effective processing may occur con- 
currently with necessary waiting periods. Notice also 
that a number of other tasks may also be active within 
the system. In fact, the greater the number of tasks run- 
ning concurrently, the more effectively system resources 
are used. Concurrent operation eliminates many time 
Wasting procedures from a real-time system. For ex- 
ample, the executive can eliminate the need for many 
timing loops where the processor simply executes a no- 
operation instruction repeatedly while waiting for an 
event to occur. 
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Fig 2 Microcomputer control for gas pump automa- 
tion. In this example, execu!ive-b3sed system simul- 
taneously controls two pumps, displays information on 
operator's console, and communicates with regional 
computer. At a given time, more or fevver . functions ■', 
could be operating concurrently. System expansion 
can be easily accomplished by adding tas-;s and • 
modular hardware 



Within the executive, tasks not only are logic, 
dependent, they are also physically independent, 
contending with each other for the use of the p 
and other system resources. The executive resolves tfa 
contention based on the priority of each task. 

In the terminal handler example, it is clear that th.* 
input handler must have highest priority, since* accept- 
able performance cannot tolerate the loss of data. Second 
highest priority is given to the echo driver, so that data 
appearing on the screen remain coordinated with the 
input. Lowest priority goes to the line buffer, since that 
function does not depend directly on an external asyn- 
chronous event. There are no particular real-time con- 
straints on the line buffer as long as the input char- 
acters are eventually processed. 

It is possible to write the entire terminal handler as 
a single large task instead of as several smaller tasks. 
Hov/cver, consideration must be given other high priority 
tasks operating within the system which may not be 
able to gain control while a low priority portion of the 
terminal handler, such as the line buffer task, is execut- 
ing. Therefore, tasks assigned as high priority are g 
erally kept as short as possible. If the terminal handW 
were written as one large task, it could tie up the entire 
processing system for a relatively trivial function. 

Task States 

Two task states have been implied— running and wait- 
ing. A running task is always the task which currently 
has the highest priority and is not suspended or waiting. 
A waiting task remains in the wait state until it receives 
a message or an interrupt for which it is waiting or until 
a specified time period has passed. The wait period can 
be timed using the system clock. 

A running task may suspend itself on some other task 
in the system. A suspended task cannot begin execution 
again until some running task orders it to resume. As 
an example, a password routine might temporarily sus- 
pend the echo driver of the terminal handler so that the 
password is not displayed. (The password routine must 
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Fig 3 System message exchanges. 
In intertask communication (a) task 

1 sends a message to an exchange, 
where it is held until task 2 requests 
message via accept. In intertask 
communication with delay (b), task 

2 waits for a message from task 1 
until data are available or until a 
certain time period has passed, 
whichever occurs first. In task con- 
trol (c), any task may suspend or 
resume any other task. In interrupt 
processing (d), an I/O interrupt is 
transformed into a message that task 
1 receives via a wait command. 
Task 1 then performs appropriate 
interrupt processing 
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Fig 4 Memory utilization. RMX/80 nucleus, de- 
vice control task, and free-space allocation mod- 
ules are linked with user tasks to form a real-time 
system. Although executive may be RAM-resident, 
it is designed to reside in p/ROM and uses RAM 
only for temporary storage and free space. User 
tasks are provided by user at generation time. 
RAM may be used by RMX/80 and all associated 
tasks for temporary storage, including stack. 



remove the password from the line buffer, or it will be 
displayed as soon as execution - of the echo driver is 
resumed.) 

A task may also be in the ready state. A ready task is 
one that would be running except that a task with higher 
priority temporarily controls the system resources. The 
executive maintains a list of all tasks that are ready to 
run. The next task to be run is always the task with 
the highest priority in the ready list. 

The running task relinquishes its control of the sys- 
tem by 

(1) Putting itself into a wait state 

(2) Suspending itself 

(3) Sending a message to a higher priority task, which 
if it has the highest current priority, becomes the run- 
ning task 

(4) Being preempted by an interrupt to a higher pri- 
ority task 

In the case of an interrupt, the executive saves the 
status (contents of registers, etc) of the interrupted task 
so that it will be restarted correctly. 



Message Exchanges 

Tasks communicate with each other by sending messages 
(Fig 3). The sending task constructs the message to be 
sent in RAM or uses a previously assembled message. 
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Fig 6 Producer task flow. 
Producer processing flow is 
opposite to that of consumer 
task. Instead of passively re- 
acting to requests from other 
tasks, producer task issues re- 
quests to which other tasks 
must respond 
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Fig 5 Consumer task flow. 
Consumer task performs ini- 
tialization and then drops into 
cyclic loop, alternately waiting 
for messages, performing func- 
tions requested by message, 
and sending an acknowledge- 
ment in form of a response 
message 



The sending task then issues a SEND command that posts 
the address of the message at an exchange. 

An exchange is simply a set of lists maintained by the 
executive. The first list contains the addresses of messages 
available at that exchange. The second list consists of a 
list of tasks that are waiting for messages at that ex- 
change When a tark enters a wait state, it specifies the 
exchange where it expects eventually to find a message. 
The task may wait indefinitely, or it may specify that it 
will only wait a specific period of time before resuming 
execution. 

Messages, together with the exchange mechanism, pro- 
vide for automatic intertask communication and also for 
task synchronization. For example, a message to a par- 
ticular task may specify that the task is to send a re- 
sponse to a certain exchange. Thus, the original task 
may request an acknowledgement response to its mes- 
sage, or it may specify that a message is to be sent to 
a third task. RMX/80 treats interrupts like messages, 
the only difference being that interrupts have their own 
set of exchanges. 

iS'ote that the sending and receiving of messages classi- 
fies tasks into two types — message consumers and mes- 
sage producers. A consumer task waits for a message, 
performs an action based on the message, and then 
returns to the wait state until another message is re- 
ceived. A producer task initiates its function by sending 
a message to another task, waits for a response, and then 
sends another message. Figs 5 and 6 graphically illustrate 
the processing within these two tasks. The distinction be- 



tween consumer and producer tasks is relative since many- 
tasks act as both consumer and producer. 

Executive Modules 

RMX./8P is supplied as a library of relocatable and link 
able modules. These modules are added selectively as 
required when the user-supplied tasks are passed through 
the link program. Only modules actually requested by 
the application are linked in. For example, if the app'* 
cation program does not specify use of the free-spat,^, 
manager, that module is not linked into the system. 

One module, the nucleus, provides basic capabilities 
(concurrence, priority, and synchronization/communi- 
cation) found in all real-time systems. Additional, op- 
tional modules may be configured with user programs 
(tasks) to form a complete application software system. 
These modules include: 

Terminal handler — Providing real-time asynchronous 
I/O between an operator's terminal and tasks running 
under the RMX/80 executive, the handler offers a line- 
edit feature similar to that of ISIS-II and an additional 
type-ahead facility. (isis-U is the supervisory system 
used on the Intellec Development System.) 
Free-space manager — This module maintains a pool of 
free RAM and allocates memory out of the pool upon 
request from a task. In addition, the manager reclaims 
memory and returns it to the pool when it is no longer 
needed. 
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Fig 7 Target microcomputer system. 
Configuration parameters are linked 
together with appropriate RMX/80 and 
user task modules. Resulting program 
is then transferred to its target SBC 
80 system via programmed p/ROMs 
or is debugged using in-circuit emula- 
tion and then transferred 



Debugger — Designed specifically for debugging soft- 
ware running under the RMX/80 executive, the debugger 
is used by linking it to an application program or task. 
Thus, it can be run directly from the single-board com- 
puter's memory. In addition, an in-circuit emulator, 
such as ICE-80, can be used to load and execute the 
debugger, providing all resources of the Intellec de- 
velopment system to simplify debugging effort. 

Analog interface handlers — Consisting of RMX/80 tasks, 
these handlers provide real-time control for SBC 711, 
724, and 732 systems. 

Diskette file systems — Giving RMX/80 users diskette 
file management capabilities, the diskette driver allows 
users to load tasks into the system and to create, access, 
and delete files in a real-time environment without dis- 
rupting normal processing. All file formats are compatible 
with ISIS-II for both single and double density systems. 

In addition to application program module or task 
requirements, the user also supplies a set of generation 
parameters. These parameters are a set of tables that 
inform the executive of the number of tasks and ex- 
changes in the system. Fig 7 illustrates the system gener- 
ation process. 



Summary 

The significance of RMX/80 to software design parallels 
the significance of the single-board computer to hard- 
ware design. Microcomputers allow designers without ex- 
tensive experience in digital systems to bring computer 
processing power into their applications. Similarly, the 
executive relieves the hardware designer of much soft- 
ware design required for real-time applications. Designed 
to facilitate growth, since new software needed to support 
hardware expansions can be supported easily by the ad- 
dition of new tasks, this executive also substantially re- 



duces recurring costs because it requires a minimum of 
memory and does not require peripheral bootstrap load- 
ing devices. RMX/80 results in economical, shorter, and 
more flexible software development efforts when design- 
ing, building, and verifying real-time user applications. 
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